I'd like to consider an alternative, that probably can't be supported here, but could be supported by tool.dynamic-metadata: We could make these lists. So then:

[[tool.dynamic-metadata]]
field = "version"
provider = "..."

[[tool.dynamic-metadata]]
field = "readme"
provider = "..."

This would be guaranteed to always run in order top to bottom, so topological sorting is not needed. This would not have a nice path to standardization, though. A small downside is that a user then has to get the order correct, but it could be an error if they don't, and you could chain these (ideal for partially dynamic metadata).

@henryiii Can I already use this in my project as the new functionality in dynamic-metadata is not releases yet?

Technically if you require version 0.11.2 or higher, yes. The dynamic-metadata dependency is not being used, the implementation is replicated inside this project. At least it is always good to get the feedback from early adopters.

More edit: There is one point to consider is that interface of tool.scikit-build.metadata vs tool.dynamic-metadata may diverge a bit for a while when we try to allow it to be an array instead of a dict. But there should still be backwards compatibility at least.

Excerpt from my pyproject.toml:

[build-system]
requires = ["scikit-build-core", "dynamic-metadata"]
build-backend = "scikit_build_core.build"

[project]
...
dynamic = ["version", "scripts"]

[tool.scikit-build]
...
experimental = true
minimum-version = "0.11.2"
metadata.version.provider = "scikit_build_core.metadata.setuptools_scm"

But this still uses 0.1.0 of dynamic-metadata:

pip install .\[test\] -v
Using pip 24.3.1 from /Users/bilke/code/ogs/ogs/.venv/lib/python3.13/site-packages/pip (python 3.13)
Processing /Users/bilke/code/ogs/ogs
  Running command pip subprocess to install build dependencies
  Using pip 24.3.1 from /Users/bilke/code/ogs/ogs/.venv/lib/python3.13/site-packages/pip (python 3.13)
  Collecting scikit-build-core
    Obtaining dependency information for scikit-build-core from https://files.pythonhosted.org/packages/2f/ce/bed84766d74cf46620bb06162ed28157deb0f6f48440893ae3a5aa452d40/scikit_build_core-0.11.2-py3-none-any.whl.metadata
    Using cached scikit_build_core-0.11.2-py3-none-any.whl.metadata (21 kB)
  Collecting dynamic-metadata
    Obtaining dependency information for dynamic-metadata from https://files.pythonhosted.org/packages/60/53/37bb267041b21973a97bb9ea6b8e0aefbec6c7fd6db5e118c529fd27e4ba/dynamic_metadata-0.1.0-py3-none-any.whl.metadata
    Using cached dynamic_metadata-0.1.0-py3-none-any.whl.metadata (3.2 kB)
    ....

dynamic-metadata is reading from tool.dynamic-metadata and scikit-build-core is reading from tool.scikit-build.metadata. I did not check what happens when both are present.

@LecrisUT Never mind, I was trying this because I got the error (without using dynamic-metadata):

scikit_build_core/builder/_load_provider.py", line 84, in _load_dynamic_metadata
      raise KeyError(msg)
  KeyError: 'scripts is not a valid field'

But it seems like the scripts field is missing: https://github.com/scikit-build/scikit-build-core/blob/main/src/scikit_build_core/metadata/__init__.py#L13-L38. I guess it should be added under _DICT_STR_FIELDS ?

Hmm, indeed it seems so, but not sure if it should be scripts or entry-points for this case. The entry-points would be quite a bit more complex, and would probably mix with the support for PEP791. For now though, patching _DICT_STR_FIELDS as you said should, work, do you want to give it a try?

This is stable/usable, it's just adding new plugins that's experimental (you'll have to set the tool.scikit-build.experimental toggle on to do that). I think our interface is fairly stable, actually, and any changes to the interface will happen inside tool.dynamic-metadata, where we don't need to worry about back-compat concerns.